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Procede de transmission de flux de donnees, flux de donnees, serveur, 
terminal, procede de reception et utilisation correspondants. 

Le domaine de T invention est celui de la transmission de donnees, sous la 
forme d'un ou plusieurs flux de donnees constitues chacun d'unites de flux 
5 elementaires. Plus precisement, Tinvention concerne F optimisation du traitement 
de ces unites de flux elementaires, lorsque celles-ci sont dependantes de, ou lier a, 
une ou plusieurs autres unites de flux. 

Lorsqu'un signal, par exemple de type multimedia, est transmis sur un 
canal unique et de fagon synchrone, le traitement d'une unite de flux ne pose pas, 
10 ou peu, de probleme. Les donnees ndcessaires ont 6t6 regues precedemment. 

Cela n'est pas le cas, en revanche, dans des systemes asynchrones, pouvant 
mettre en ccuvre plusieurs canaux de transmission, et/ou plusieurs serveurs 
distribuant chacun une partie du signal utile. C'est par exemple le cas de la 
transmission, ou de la diffusion, sur un r6seau type IP. * 7 

15 Dans ce cas, il arrive que Ton regoive une unite de flux qui est sehsSe en 

completer d' autres, qui n'ont pas 6t6 regues. II peut par exemple s'agir de donnees 
d'enrichissement de donn6es d'un niveau hi6rarchique sup^rieur, les donnees 
6tant coddes h. l'aide d'un codage hi6rarchique (un flux pouvant alors 
correspondre a un niveau hiSrarchique donn6). Le traitement des donnees 
20 d'enrichissement va alors donner un resultat aleatoire, conduisant en g£n6ral a une 
forte degradation du signal restitu6, voire h. un blocage complet du d6codeur. 

L'art anterieur en mati&re de synchronisation multimedia est repr^sente 
essentiellement par les protocoles de transport bas6s sur RTP et par MPEG-4 
(Synchronization Layer). Dans Fapproche utilisSe, les mecanismes de 
25 synchronisation ont ete principalement congus pour synchroniser temporellement 
un flux audio et un flux video, afin qu'iis soient presentes sans d£calage. Ces 
informations etaient v6hiculees au moyen d'un systdme d'estampillage temporel 
(une horloge de reference, des estampilles de decodage et de presentation). 

Avec I'av&nement de codages hi6rarchiques, oil differents niveaux 
30 d'enrichissement temporel et spatial sont utilises afin de produire une trame 
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presentable, l'inventeur a constate qu'un nouveau besoin de synchronisation 
apparalt. 

En effet, il est necessaire de synchroniser les flux avant leur decodage (et 
non pas seulement a leur presentation). Cette contrainte s'avere plus complexe 
5 que la synchronisation de presentation car il est necessaire d' identifier quelles 
sont les unites necessaires au decodage d'une unite afin de produire une trame 
correcte. Un seul decalage peut rendre inutile tout un flux ainsi que tous les flux 
bases sur ce dernier. II s'agit la d'un probleme nouveau, et non Evident, identifie 
par Tinventeur. 

10 Un probleme similaire se pose lorsqu'une unitd de flux recue doit 6tre 

decod6e, ou decryptee, a l'aide d'informations (par exemple une cl6 de decodage) 
que le terminal aurait da recevoir, mais qu'il n'a pas recues. A nouveau, le resultat 
du decodage sera au minimum inefficace, en general nuisible (en termes de signal 
restitu<S), et peut conduire au blocage du terminal. Dans les deux cas, un traitement 

15 inutile et nefaste aura 6t6 effectu6. 

Un autre probleme important rencontre dans les systemes de diffusion 
(« multicast » ou « broadcast ») est que les memes informations doivent etre 
multidiffusees, pour permettre a un utilisateur se connectant a un instant 
quelconque de recevoir l'integralite du ou des flux qu'il a selectionnes. Cet aspect 

20 specifique est deja discut6 dans la demande de brevet EP-0 1 4600462, non encore 
publiee, aux noms des titulaires de la presente demande de brevet. Selon cette 
technique, le traitement est effectu6 au niveau du transport, ce qui impose un 
traitement de chaque unite de flux, tenant compte des specificites des differents 
types de transport. 

25 L'art anterieur en matiere de representation multimedia dans des scenarii 

« broadcast » et « multicast » est decrit dans la specification du « carousel MPEG- 
4 ». Cependant un certain nombre de fonctionnalites sont interdites ou rendues 
extremement consomma trices en d6bit. Dans les deux scenarii de delivrance 
consideres, il est necessaire dc signaler des points d'entree a la presentation 




multimedia k tout moment. Ceci se traduit par une repetition des donnees relatives 
k la description de la scene : scene BIFS, textures. 

Des que le contenu multimedia devient riche, cette repetition simple n'est 
pas acceptable et conduit k des temps de telechargement excessifs. Par ailleurs, 
5 cette specification ne permet pas de diffiiser certains elements multimedia (clips 
audio/video de courte duree). 

L'invention a notamment pour objectif de pallier ces differents 
inconvenients de Tetat de Tart. 

Plus precisement, un objectif de l'invention est de fournir une technique 
10 permettant de gerer efficacement des unites de flux, lorsque celles-ci dependent 
de, ou sont liees k, une ou plusieurs autres unites de flux. 

Notamment, un objectif de l'invention est de fournir une telle technique, 
qui permette la gestion de flux lies, en particulier dans le cas de donnees codecs a 
1'aide d'un codage hierarchique, ou un codage comprenant un codage associant 
15 des donnees de base et des donnees d'enrichissement. 

Un autre objectif de Tinvention est de fournir une telle technique, 
permettant d' assurer efficacement la gestion du decodage, ou du decryptage, 
d" unites de flux. 

Encore un autre objectif de 1* invention est de fournir une telle technique, 
20 qui permette d'optimiser la transmission de scenarii multidiffuses, et notamment 
de reduire la quantite de ressource utilisee, sans reduire la qualite de la reception. 

L'invention a pour objectif, en d'autres termes, d'optimiser les traitements 
effectues, dans les terminaux, tant en quantite qu'en qualite. 

Ces objectifs, ainsi que d'autres qui apparaitront par la suite, sont atteints 
25 selon l'invention k Taide d'un precede de transmission d'au moins un flux de 
donnees vers au moins un terminal, le ou lesdits flux etant organises en unites de 
flux. Selon l'invention, au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fagon k optimiser les traitements dans ledit terminal et/ou le debit 
30 utile du ou desdits flux. 



On dispose ainsi d'un systeme de synchronisation logique, permettant de 
faciliter la gestion des unites de flux, de limiter les traitements dans les terminaux, 
d'ameliorer la qualite de restitution,. . . 

Le format de donnees ainsi defini, selon i'invention, peut 6tre mis en 
5 oeuvre non seuiement pour la transmission et la reception de flux, mais egalement 
pour leur diffusion, leur enregistrement et leur stockage. 

Selon un aspect avantageux de I'invention, qu'au moins un desdits 
pointeurs pointe vers au moins une unite de flux dudit flux ou d'un autre flux 
susceptible d' avoir ete recue precedemment dans un terminal, dite unite anterieure 
10 necessaire, de fa 5 on qu'un traitement de ladite unite de flux ne soil pas effectue, 
dans ledit terminal, si la ou lesdites unites ant6rieures n6cessaires n'ont pas 6t6 
re9ues. 

Cet aspect de I'invention repose en effet notamment sur 1' identification du 
probleme nouveau de la synchronisation « arriere » des flux ou des unites de flux, 

15 et sur l'observation non evidente que la solution la plus efficace est de ne pas 
trailer les unit6s de flux lorsque l'on ne dispose pas de tous les elements pour le 
faire. II apparait en effet preferable, en termes de restitution de signal, d'ignorer 
une unit6 de flux plutot que d'en effectuer un decodage qui conduira a une 
deterioration du signal restitue, voire a un blocage complet du terminal. 

20 De facon avantageuse, le procede de I'invention comprend la transmission 

d'au moins deux flux de donnees transmis separ6ment, une unite de flux d'un 
premier flux pointant vers au moins une unite anterieure necessaire d'au moins un 
second flux, ladite unite de flux du premier flux comprenant des donnees 
d'enrichissement des donnees contenues dans le ou lesdits seconds flux. 

25 Dans ce cas, lesdits flux de donnees peuvent avantageusement 

corresponds a des niveaux hierarchiques different* d'un codage hierarchique, le 
traitement d'une unite de flux d'un niveau hierarchique donn6 n'etant effectue que 
sl ies unites de flux du ou des niveaux hiexarchique* inKricurs correspondents out 
■ite term. 

, , „-,;.-- i=. ii„ .--pi .v-.in.cr :;ur -.-h rvwiu unc unite mterieurc. 




definissant une sequence d* unites anterieures necessaires. 

Selon une caracteristique avantageuse de V invention, au moins un desdits 
pointeurs permet de retrouver au moins une unite ant6rieure n£cessaire 
comprenant des donnees permettant le d£codage et/ou le d£cryptage de T unite de 
5 flux consideree. 

Pref^rentiellement, la ou lesdites unites anterieures necessaires 
comprennent des donnees permettant & un terminal de decider si les donnees 
d'une unite de flux consider^ doivent etre decodees et/ou decrypt6es, puis 
affichees apres decodage. 
10 Selon une autre mise en ccuvre avantageuse, au moins un desdits pointeurs 

pointent vers des donn6es susceptibles d'etre connues dudit terminal, de fagon que 
ce dernier puisse decider de sa capacity ou de son incapacite a traiter Tunit6 de 
flux correspondante. 

De fagon avantageuse, selon un autre aspect de V invention, au moins une 
15 desdites unites de flux comprend au moins un pointeur pointant vers au moins une 
unite de flux dudit flux ou d'un autre flux, susceptible d'etre regue prochainement. 

. Pr6f6rentiellement, la ou lesdites unites de flux susceptible d'etre regue 
prochainement possdde en marqueur, permettant de faire un lien avec le ou lesdits : 
pointeurs. 

20 Ainsi, avantageusement, les pointeurs d'au moins deux unites de flux 

similaires transmises & des instants distincts peuvent pointer vers une m§me unit6 
de flux susceptible d'etre regue prochainement. 

De fagon preferentielle, le proced£ de 1' invention met en oeuvre un 
indicateur indiquant le r61e du ou des pointeurs, parmi au moins deux des roles 
25 appartenant au groupe comprenant : 

designation d'au moins une unite de flux anterieure devant etre 
d6cod6e pour permettre la prise en compte de 1' unite de flux 
consideree ; 

designation d'au moins une unite de flux anterieure comprenant des 
30 donnees necessaires au decodage et/ou au d6cryptage de l'unite de 



flux consid6r6e, et/ou d'une reference a un etat d'un systeme de 
protection ; ; 

designation d'au moins une unite de flux post^rieure. 
Avantageusement, au moins certaines desdites unites de flux comprennent 
5 un descripteur de dependance, definissant ledit role. 

De facon avantageuse, au moins certaines desdites unites de flux 
• comprennent un marqueur de dependance, permettant son identification en tant 
qu' unite anterieure n6cessaire et/ou un marqueur d' identification de ladite unit6 de 
flux dans ledit flux. 

10 Pref6rentiellement, le proced6 de l'invention est mis en ceuvre au niveau 

synchronisation, de fagon qu'aucun traitement prealable d'une unit6 de flux recue 
ne soit n6cessaire. 

L'invention concerne egaiement un ou plusieurs flux de donnees transmis 
selon le precede de transmission decrit ci-dessus. Comme deja mention^, un tel 
15 format de donnees peut Stre utilise pour la transmission, la diffusion, la reception, 
l'enregistrement (par exemple via un magn6toscope ou un enregistreur de disques 
optiques) et le stockage de donnees (par exemple sur un CD-ROM, une bande, un 
serveur distant. . .). 

On notera egaiement que l'invention permet de combiner aisement 
20 plusieurs de ces aspects. Par exemple, certains flux peuvent 6tre diffuses, et 
d'autres fournis sur un CD-ROM, ou un serveur, la connaissance des seconds 
6tant necessaires pour decoder (ou optimiser) les premiers. 

Un tel flux de donnees est organist en unites de flux transmises 
independamment les unes des autres, au moins certaines desdites unites de flux 
25 comprenant au moins un pointeur poiutant vers au moins une unit€ de flux dudit 
flux ou d'un autre flux, de facon a optimiser les traitements dans ledit terminal 
et/ou le d<5bit utile du ou desdits flux. 

Avantageusemem, au moins un desdits poinicuis pointc vers au moins une 
unite dc flux d.idit flun ou d'un autre flux susceptible d'avoir 6t6 recue 




traitement de ladite unite de flux ne soit pas effectug, dans ledit terminal, si la ou 
lesdites unites anterieures necessaires n'ont pas ete regues. 

L* invention concerne egalement les serveurs de donnees destinees a etre 
transmises vers au moins un terminal, sous la forme d'au moins un flux de 
donnees organist en unites de flux transmises independamment les unes des 
autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, de 
fagon & optimiser les traitements dans ledit terminal et/ou le debit utile du ou 
desdits flux. 

I/invention concerne encore les tenninaux apte a recevoir au moins un 
flux de donnees organise en unites de flux transmises independamment les unes 
des autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, de 
fagon & optimiser les traitements dans ledit terminal et/ou le debit utile du ou 
desdits flux. 

L' invention concerne egalement les proced6s de reception d'au moins un 
flux de donh6es organise en unites de flux transmises ind6pendamrnent les unes 
des autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, de 
fagon a optimiser les traitements dans ledit terminal et/ou le debit utile du ou 
desdits flux. 

De fagon avantageuse, au moins un desdits pointeurs pointe vers au moins une 
unite de flux dudit flux ou d'un autre flux susceptible d* avoir 6t6 regue 
precedemment dans un terminal, dite unite anterieure necessaire, et le procede de 
reception comprend les etapes suivantes : 

analyse du ou desdits pointeurs d'une unite de flux ; 

traitement de ladite unite de flux si la ou lesdites unites anterieures 

necessaires ont ete regues. 
^invention concerne enfin les utilisations du precede de transmission, en 
particulier pour une des applications appartenant au groupe comprenant : 



diffusion syst6matique d'un message avant acces a un programme 
seiectionn6 par un utilisateur ; 

acces conditional a un niveau de quality particulier et/ou a une 
option particuliere d'un programme ; 
5 - television interactive. 

D'autres caracteristiques et avantages de l'invention apparaitront plus 
clairement a la lecture de la description suivante d'un mode de realisation 
preferentiel de l'invention, donne a titre de simple exemple illustratif, et des 

dessins annexes, parmi lesquels : 

10 . la figure 1 illustre le principe de la gestion de la dependance d'un 

flux de donnees par rapport a un autre, selon I' invention ; 
la figure 2 presente une mise en ceuvre de l'invention, dans le cas 
de la diffusion d'un flux (« broadcast ») et de sa reception par deux 
terminaux, sous la forme de sessions decalees dans le temps ; 

15 . ia figure 3 illustre le cas d'une synchronisation liee au dexodage, ou 

au decryptage, d'une unite de flux (TPMP) ; 

la figure 4 presente une variante du cas de la figure 3, avec deux 
points de protection (decodage et rendu). 
Le mode de realisation pref6rentiel decrit ci-apres concerne notamment la 
20 transmission de flux, dans un systeme multimedia, notamment du type MPEG4. 
1 - rappels snr la tec hnique anterieuraj. 

La technique anterieure ne permet ni de prendre en compte la transmission 
efficace (en termes de d6bit et de fonctionnalite) de scenes multimedia dans des 
scenarii multicast ou bien broadcast ni la synchronisation de flux interdependants 
25 des elements lies au contenu de type clefs de contr61e d' acces. 

i i rep r^Pntntion multimedia dans de.s .sc6narii broadcast et multicast 

Une solution est proposee dans la specification du « carousel MPEG-4 ». 
Ccpendunt un Certain nombre de fonctionnalite, sent interdiles ou rendues 
extrememenl consom matrices cn debit. Dans les deux scenarii de delivrance 
v, ii ^ic-. 3 3irc Oo -^nakr de?. noint" d'enir-v- h la prcacuiation 




multimedia a tout moment. Ceci se traduit par une repetition des donnees relatives 
a la description de la scene : scene BIFS, textures. 

Des que le contenu multimedia devient riche cette repetition simple n'est 
pas acceptable et conduit a des temps de t61echargement excessifs. Par ailleurs, 
cette specification ne permet pas de diffuser certains 61ements multimedia (clips 
audio/video de courte duree). 

Par ailleurs, dans la demande de brevet non encore publiee EP-01 
4600462, les donnees etaient vehiculees au niveau du transport. En revanche, 
selon 1' invention, le tout se trouve au niveau de Ia couche dite de synchronisation 
qui est independante du transport. 

Ceci a pour avantage de s'abstraire des differents types de transport et 
d'unifier les informations de synchronisation temporelle et logiques ainsi que les 
marqueurs d'acces aleatoire en un meme point, ceci permet de calculer a un 
endroit unique la d6cision de conserver ou pas l'unite. II s'avere que l'on connalt 
par ailleurs bien plus d' informations sur le flux, ce qui permet de specialiser les 
decisions par type de flux (interessant pour video/audio par rapport a BIFS, etc). 
1.2 synchronisation multimedia 

L'art anteriew en matiere de synchronisation multimedia est represents 
essentiellement par les protocoles de transport bases sur RTP et par MPBG-4 
(Synchronization Layer). Dans l'approche utilisee, les mechanismes de 
synchronisation ont 6t6 principalement congus pour synchroniser temporellement 
un flux audio et un flux video, afin qu'ils soient presents sans decalage. Ces 
informations etaient v6hiculees au moyen d'un systeme d'estampillage temporel 
(une horloge de reference, des estampilles de d6codage et de presentation) 

Avec l'avenement de codages hierarchiques ou de differents niveaux 
d'enrichissement temporel et spatial sont utilises afin de produire une trame 
presentable, un nouveau besoin de synchronisation apparait. En effet, ii est 
necessaire de synchroniser les flux avant leur decodage (et non pas seulement a 
leur pr6sentation). Cette contrainte s'avere plus complexe que la synchronisation 
de presentation car il est necessaire d'identifier quels sont les unites necessaires au 



decodage d'une unite afin de produire tine trame correcte. Un seul decalage peut 
rendre inutile tout un flux ainsi que tous Iqs flux bases sur ce dernier. Comme on 
le voit, il s'agit d'un probleme de dependance logique entre unites h decoder. 

Un intervalle de temps reduit est deja pris en compte dans MPEG-4 video, 
5 ' mais celui-ci n'est pas accessible aux couches systeme. 
1 .3 protection des donnfes 

Un troisi&me cas de synchronisation n'est pas aborde dans Tart anterieur : 
celui de la synchronisation d'un flux de protection de donnees lie a un flux 
multimedia. 

10 Dans ce cas, il est necessaire de s 'assurer que toute unit£ de flux 

multimedia sera d^cryptee avec une cle correcte avant d'etre d6codee (le cas 
dcheant les rdsultats ont toute chances d'gtre catastrophiques). Des lors que les 
flux ne sont pas assures d'etre synchrones, les outils de synchronisation ne 
peuvent assurer ceci. 

15 Cette fois-ci, Tentr6e du d6codeur et la sa sortie sont des points de 

synchronisation fla trame decod6e peut & son tour etre cryptee). 
2« principes de Pinvention 

Les buts de Pinvention sont notamment de permettre : 

o La diffusion multicast et broadcast de scenes multimedia ; 
20 o La synchronisation logique du decodage multimedia. 

Ceci est obtenu h 1'aide de mecanismes de signalisation permettant 
d'atteindre ces deux objectifs : 

o Mdcanisme permettant configurer un flux afin que chacune des 
unites temporelles le composant s'identifient de fagon 
25 parametrable. 

o Mecanisme de chatnage avant pour les scdnarii de 
diffusion/broadcast. 
Les elements techniques essentiels de 1 invention sont ainsi : 

o Element« de synchronisation logique entre elements de plusieurs 
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de donnees) ; 

« La solution permet pour chajque element du flux d'indiquer de quel 
type d'616ments il depend, et de quels elements en particulier il 
d6pend. Plusieurs mises en oeuvre sont possibles. 
On utilise notamment, sous toute forme de realisation : 

• Desciipteur de d6pendance : « DependencyDescriptor » ; 

• Marqueur de dependance : « DependencyMarker » 
(Optionnellement) ; 

• Pointeur sur Tunite dont on depend : « DependencyPointer » ; 

• Marqueur (idendfie une unit6 du flux) : « marker » 
(Optionnellement). 

2* Description detaillee d'au moins un mode particulier de realisation t 

3. 1 specification MPEG4 

L' annexe 1 pr£sente de fagon detaillee un exemple de mise en oeuvre de 
l'invention pour des normes de type MPEG, sous la forme d'une specification 
MPEG-4. • 

3.2 comportement du r^cepteur 

Le terminal re?oit un IOD (InitialObjectDescriptor) celui-ci fait reference 
par F intermediate de leurs descripteurs (ObjectDescriptor) k au moins un objet 
de description de sc&ne graphique (flux BEFS : FJBIFS) et optionnellement a au 
moins un objet de description d'objets graphiques (flux d'OD : F_OD). Le 
terminal va ouvrir ces flux en se basant sur les informations presentees ci-aprfes. 

Chacun de ces descripteurs d* objet contient un descripteur par flux 
61ementaire (ES) qui le compose (ESDescriptor). Chaque ESDescriptor contient 
un champ dependsOnESID et un SLConfigDescriptor. 

Le champ dependsOnESID permet de construire le graphe des 
d6pendances entre flux identifies par leur ESID. 

L' objet SLConfigDescriptor permet de configurer les outils de 
synchronisation. 

On trouvera dans l'objet SLConfigDescriptor la possibility de configurer le 
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recepteur afm qu'il verifie les differentes dependances de la facon suivante : 

DependencyMarker //permet de configurer le 

stream afin qu'il identifie ses paquets. 
5 { 

int (5) markerLength; 

} 

DependencyDescriptor /Apenw* de decrire les 

liens de dependance. 
10 { 

int(2) mode; // 0 : mode version par DTS, 

// 1 :mode version par ED, 
// 2 : mode scalable, 
//3 :modeIPMP 

15 //si mode=l la ddpendance se fait % a un 

marqueur dans le stream. 

// si mode=3 la d6pendance se fait de facon opaque 

(le systeme IPMP se doit de 

// comprendre la dependance et de valider ou 
20 non le decodage/decryptage. 

// eventuellement en utilisant un marker. II 

s'agit done d' un code 

// qui permet au systeme de protection de 

savoir s'il s'agit ou non d'une 
25 // unit6 decryptable (ou non) 

// si mode=0 ou mode=2, la dependance est 

calculee sur le DTS 

// par cont:cqi"ent depLenglh = dtsLenath dans 

le SLConfig correspondant. 

i.j.;.-' iI-OLCtl'-ili 
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if (mode=l j| mode==0) 

{ : 

int(depLength) value; //valeur de la premiere unite a 

chercher. 
} 

} 

Ainsi, un flux peut se declarer dependant d'un autre flux (lui-m8me, un 
media normal ou IPMP). Dans ce cas, il decrit dans sa configuration SL comment 
il va signaler cette dependance (Dependency descriptor) dans quatre modes 
distincts : 

3.2. 1 Mode version par DTS et par ID (modes Oet I) : 

Le flux va signaler pour chacune de ces AccessUnits (AU)une 
dependance avant dans le flux lui-meme. Dans d'autres termes l'AU(n) 
precise quelle est la prochaine AccessUnit a decoder. Cette signalisation se 
fait au moyen d'un marqueur dans chaque paquet qui d6crit ou bien, dans 
le mode 0 le DTS de la prochaine Access Unit (unique) ou bien l'ID de la 
prochaine Access Unit dans le mode 1. 

Dans ce cas on rajoute la valeur du premier element a recuperet 
II peut par exemple s'agir d'un flux BIFS en mode 
broadcast/multicast. 

3.2.2 Mode scalable (mode 2) ; 

Le flux va signaler pour chacune de ces Access Units une 
dependance par rapport a un flux dont il depend. Ce flux est suppose 
unique. 

Ce principe est illustre par la figure 1. L'unite de flux 11 d'un flux 
dependant 10 comprend classiquement un en-tete (SLHeader) 111 et un 
champ de donnees (SL payload) 112. L'en-tete 111 comprend notamment 
deux pointeurs Depl et Dep2, qui d6finissent des liens de dependance 12 
et 13 avec des unites de flux 141 et 142 respectivement d'un flux de base 
14, dont la connaissance est necessaire pour traiter l'unite de flux 1 1. 
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3.2.3 Mode IPMP (mode 3) : 

Le flux va signaler pour chacune de ces AccessUnits un 
identificateur qui permet au systeme de protection de donn6es de decoder 
l'unit6. Celui-ci etant donne ce marqueur peut repondre si oui ou non il sail 

5 decrypterl' unite. 

Le SLConfigDescriptor peut contenir un ou plusieurs 
DependencyDescriptor et un ou plusieurs DependencyMarker, ce qui permet de 
regler les differents cas de ddpendance dans le flux. (A priori un seul 
DependencyMarker suffit, mais on peut e^entuellement en avoir plusieurs) 
10 Ainsi si le SLConfig contient DependencyMarker, il signalera un ID de 

version pour chacun de ses paquets (modes 1 et 3). 

Dans l'entete d'un paquet SL correspondant a une AccessUnit on trouvera 

done : 

o Pour chaque dependencyMarker du SLConfigDescriptor, un 
j 5 marker de longueur markerLength. 

o Pour chaque DependencyDescriptor un dependencyPointer de 

longueur depLength. 
Une fois ces differents marquages realises, le systeme est a meme de : 
a) Fonctionner en mode « broadcast » grace aux modes 0 et 1 ; 
20 b) Gerer les dependances de scalability ; 

c) Gerer les dependances EPMP ; 
et les combinaisons de a),b),c). 

<t -x TW.ri ptio" fnnctio p "«n«nt en mode IPMP 

Lors de la reception de rObjectDescriptor relatif a un objet, le terminal 
25 examine le SLConfigDescriptor pour chacun des flux associes. Ceci permettra de 
decoder l'entete des paquets SL pour chacun des flux : en particulier de decoder 
les marqueurs. 

Dans lc cas IPMP il y aura des DTS et/ou des dependencyPointer, ainsi 

que cela est illusire en figure 3. 

rhajii* .-.n M flur.. avanl que cflui-ci nc decode, il eta t^ite par 




le systeme IPMP 32, en lui fournissant au moins les donnees suivantes identifiant 
de flux ESID, DTS, dependencyPointer (I?M) 3L Le systfeme IPMP repond alors 
(33) s'il est en mesure de traiter (decrypter) l'AU, en consid€rant 1'information 
311 (Code Dec) relative au decodage. Si ce n'est pas le cas et que le DTS de 
5 l'unite est arriv6 h maturite, l'AU est detruite (34). On n'essaie done pas de 
decoder des AU non coherentes. 

Dans 1'exemple de la figure 4, on retrouve d'une part les elements de la 
figure 3, et d'autre part un traitement lie a la restitution de l'image, aprfes son 
decodage 4L En effet, a i'aide du champ 312 (CodeComp), on peut transmettre 
10 des donnees relatives k la composition, tel que l'ajout d'un tatouage ou d'un 
message sur l'image. Si le systeme de protection de donn6es 32 ne sait pas gerer 
cette composition (il ne sait pas afficher 1' image (42)), par exemple parce que le 
decodeur ne dispose par du tatouage requis, l'image n'est pas affich6e (43). 

On peut egalement pr6voir que la trame sera marquee par exemple d'un 
15 logo, qui disparait si le decodeur dispose de la bonne cl6. 

3.4 Description du fonctionnement en mode multicast/broadcast 
Ce fonctionnement est illustr6 en figure 2, qui pr6sente : 
le flux 6xms 21 ; 

le flux re^u par un premier recepteur (session 1) 22 ; 
20 - le flux re?u par un premier recepteur (session 2) 23. 

La session 1 d€marre sur le paquet 211, puis prend en compte l'unite de 
flux 213, sur lequel pointe (24) l'unite de flux 211, puis l'unite de flux 215, selon 
le lien 25. 

La session 2, entamee tegerement apres, d6marre avec I'unit£ de flux 212, 
25 qui pointe (26) sur l'unite de flux 214, 

Selon V invention, deux (ou plus) unites de flux peuvent pointer sur une 
m§me unite de flux suivante. C'est le m<5canisme de fusion 27 : les unites de flux 
213 et 214 pointent toutes deux sur l'unite de flux 215. Ainsi, bien qu'ayant 
debutdes a des instants differents, les deux sessions utilisent, apres une phase « de 
30 rattrapage, les memes unites de flux 215. Cela permet clairement d'am&iorer le 
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rendemenL 

On decrit plus precisement ce fonctipnnement. 

Lors de la reception de PObjectDescriptor, le terminal examine le 
SLConfigDescriptor pour chacun des flux associes. Ceci permettra de decoder 
5 i'entete des paquets SL pour chacun des flux : en particulier de decoder les 
marqueurs. 

Dans le cas Multicast/Broadcast il y aura des done des DTS, au moins un 
dependencyPointer en mode 0 ou 1, et un marqueur (mode 1 « par ID ») . Le 
terminal sait done quelle est la premiere unite a recup6rer pour chacun des flux. II 
10 essaiera done de recuperer la premiere unite correspondant & chaque flux. 

S'il regoit la premi&re unite, alors il peut commencer h afficher le contenu. 
Chaque unite decrit dans le « dependencyPointer » la prochaine unit6 & recevoir et 
le DTS/marqueur identifie chaque unite de fagon unique. 

Si le terminal ne re§oit pas la premiere unite (il peut s'en rendre compte ou 
15 bien par time-out ou des qu'il re$oit une unite pour ce flux de type RAP=1 qui ne 
correspond pas au marqueur souhaite). II se deconnecte (fermeture complete de 
session) et essaie de se reconnecter. 

On notera que ce m6canisme prend en compte la fusion de sessions. 
On notera 6galement que le mode par ID est necessaire des que Ton ne sait 
20 pas & Tavance le DTS de la prochaine unite. 

Ce mecanisme est utilis6 notamment pour BIFS,OD,Textures, clips audio, 
clips video dans MPEG-4. Pour la video/audio streamee il ne sera pas utilise. 
3.5 Description du fonctionnement en mod e scalable 

Lors de la reception de PObjectDescriptor, le terminal examine le 
25 SLConfigDescriptor pour chacun des flux associes. Ceci permettra de decoder 
Tentete des paquets SL pour chacun des flux . Pour de la video scalable, un flux 
servira de base et un ou plusieurs aulres flux dependront de celui-ci, Chaque flux 
dependant du fhi;c de base decbrera un DependencyDescriptor. 

Pour chaque AU du flux d'amelioration, il referencera grace au 
v, -V:i-i>:lcr.^vP»-i'U^r k-3 DT* ds>: fi V dv finn de base doni il depend. 




Dans la plupart des cas, il y aura deux dependencyPointer dans le flux 
d'amelioration afin de pointer sur les deux AU de reference de la video de base. 
3-6 Descripti on du fonctionnement en mode broadcast+lPMP 

Dans ce cas, le BIFS, par exemple contiendra deux dependency Descriptor 
dans la configuration SL. L'un pour le mode broadcast, l'un pour IPMP. n 
contiendra un marqueur si le mode broadcast est par ID. 
4, Exemples d'applicatinns : 

4d Diffusion d'une publ icite avant de commencer un programme 

Dans de nombreux cas de streaming sur Internet, les fournisseurs de 
contenu envoient systematiquement une publicite avant d'envoyer le contenu lui- 
m8me. Les scenarii internet gtant unicast (client-serveur), cela se fait en deux 
phases : telechargement de la publicity la fin de la publicite" declenche le 
lancement du streaming de la video. 

Dans un scenario multicast ou broadcast, oil Ton ne peut avoir recours a un 
fonctionnement client-serveur, il n'y a pas de notion de requSte, de ce fait, 
1'utilisateur n'a generalement acces qu'a 1'etat courant de la presentation. 

Grace au mecanisme de reference avant ce scenario devient possible en 
multicast ou bien en broadcast. 

En effet, il est possible d'envoyer de facon cyclique la publicite" et de 
fusionner vers le programme en cours en fin de publicity. 

Ceci permet de s'assurer par exemple que tout utilisateur visualisera la 
publicite au d6but (Pendant ce temps la, on peut realiser le telechargement du 
contenu pour la suite de facon efficace et incrementale). 

Des applications du m6me type peuvent Stre, pour chaque film diffuse, une 
notification de la categorie du film (accord parental, moins de 16 ans, etc.). 

4,2 Acces conditionnel gcajabjg 

L'idee ici est d'envoyer le meme flux (unique) video et audio pouvant etre 
visualise de facon differente en fonction des droits des utilisateurs. La 
signalisation des dependances des trames video par rapport aux cles de protection 
permet de decoder uniquement celles dont on a la cle\ On peut done decoder 
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toutes les images pour celui qui possede toutes les cles, _ des images pour un 
utilisateur ayant moins de droits, etc.,. Ceci permet de faire de Faeces 
conditionnel de facon plus echelonnable.(6chelonnelabUite temporelle ici) 

Le scenario, plus complex, et plus utile est celui oix Von a plusieurs flux 
et ou l'on peut jouer a la fois sur l'echelonnabilite temporelle et en resolution 

Avec ce systeme de dependance par trame, il est done possible de moduler 
de fagon quasi-continue l'acces aux medias. 

On peut done imaginer que certains utilisateurs auraient des cles 
permettant de recevoir le son sur 5 voies (son spatialise) et d'autres uniquement le 
son st6reo. Ce qui permettrait egalement une facturation plus fine. . . 
A ^ X^visjofl Interactive MPEG-4 

Au lieu de considerer que I'applicatif de la « set-top box » est statique, on 
peut consider que tout cet applicatif est une application MPEG-4 qui permet 
d'atteindre les differentes chaines (m6canisme d'inline). Cette application MPEG- 
4 serait active 24h/24h et permettrait de reconfigurer completement les interfaces 
graphiques, etc. . . 

La technique de diffusion de scene permettrait de tel€charger efficacement 
1'interface graphique (BIFS/Textures/OD) ainsi que la partie appUcative (MPEG- 
J). 

Ceci permet un d6ploiement/red6ploiement rapide. 
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ANNEXE 

EXEMPLE DE SPECIFICATION DE TYPE MPEG-4 
SELON L'INVENTION 

5 1- Definitions 

ii Unite de flux f AU : Acre.™ fTnir) 

Une unite de donnees accessible individuellement dans un flux elementaire 
{elementary stream). Une unite de flux (ou unite d'acces) est la plus petite entite" a 
laquelle une information temporelle peut etre attribu6e. 
10 1.2 Oh jet Audjovisuel 

Une representation d'un objet naturel ou synthase - (virtuel) qui se 
manifeste de fagon auditive et/ou visuelle. La representation correspond a uh 
, noeud ou a un groupe de nocuds dans la description de la sequence BIFS. Chaque 
objet audiovisuel est associe a zero, un ou plusieurs flux 61ementaires {elementary 
15 streams) utilisant un ou plusieurs descripteurs d'objet {object descriptors). 

1*2 Sequence Audiovisuelle (AV Scene ) 

Une serie d'objets audiovisuels avec des informations decrivant la scene 
qui definissent leurs attributs spatiaux et temporels incluant les fonctionnements 
resultant de r objet et des interactions de l'usager. 
20 14 Format Binaire de Sjcjne (BIR<tt 

Une representation codee d'un format de description de scene 
parametrique. 
1.5 Terminal 

Un systeme qui envoie ou recoit et pr^sente la representation codee d'une 
25 scene audiovisuelle interactive comme definit par ISO/IEC 14496-1. Cela peut 
etre un systeme autonome ou partie d'un systeme ^application se soumettant a 
ISO/IEC 14496. 

2 S Abreviati ons et symjb_oIgs 



Unite d' Acces, ou Unite de Flux (Access Unit) 
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AV 


Audiovisuel (Audio-visual) 


BIFS 


Format Binaire de Scene (Binary Format for Scene) 


CM 


Memoire de Composition (Composition Memory) 


CTS 


Estampille Temporelle de Composition (Composition Time Stamp) 


CU 


Unite de Composition (Composition Unit) 


DAI 


Interface d' Application DMIF (voir ISO/IEC 14496-6) (DMIF Application Inte 


DB 


Memoire Tampon de Decodage (Decoding Buffer) 


DTS 


Estampille Temporelle de Decodage (Decoding Time Stamp) 


ES 


Flux 6lementaire (Elementary Stream) 


ESI 


Interface de Flux £lementaire (Elementary Stream Interface) 


ESID 


Identifiant de Flux El6mentaire (Elementary Stream Identifier) 


FAP 


Parametres d' Animation Faciale (Facial Animation Parameters) 


FAPU 


Unit€s FAP (FAP Units) 


NCT 


Tables de Codage de Nceuds (Node Coding Tables) 


NDT 


Nceud de Donnee Type (Node Data Type) 


OCI 


Informations sur le Contenu de I'Objet (Object Content Information) 


OCR 


Reference d'Horloge Objet (Object Clock Reference) 


OD 


Descripteur d' Objet (Object Descriptor) 


ODID 


Identifiant de Descripteur d'Objet (Object Descriptor Identifier) 


OTB 


Base de Temps Objet (Object Time Base) 


PLL 


Boucle h Verrouillage de Phase (Phase Locked Loop) 


QoS 


Quality de Service (Quality of Service) 


SDM 


Modele de Decodeur de Systeme (System Decoder Model) 


SL 


Couche de Synchronisation (Synchronization Layer) 


SL-Packet 


Paquet de la Couche de Synchronisation (Synchronization Layer Packet) 


SPS 


Flux de SL-Packets (SL-Packetized Stream) 


STB 


Base de Temps Systeme (System Time Base) 


ITS 


Texie vers Parole (TevU-To-Speerh) 


URL 


Localisuteur de Rcssources Universelles (Universal Resource Locator) 




'->)•- H-jf. vjd.», iVi.jco Object Planet 
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VRML Langage de Modelisation de R6alit6 Virtuelle (Virtual Reality Modeling Languag. 

3, Configuration d'en tete de paquet SI, 

3J Svntaxe 



class SLConfigDescriptor extends BaseDescriptor : bit (8) 
tag=SLConfigDescrTag { 
bit (8) predefined; 
if (predefined=0) { 

bit (1) useAccessUnitStartFlag; 

bit(l) useAccessUnitEndFlag,- 

bit (1) useRandomAccessPointFlag; 

bit (1) hasRandomAccessUnitsOnlyFlag; 

bit(l) usePaddingFlag; 

bit (1) useTimeStampsFlag; 

bit(l) useldleFlag; 

bit (1) durationFlag; 

bit (32) timeStampResolution; • 

bit (32) OCRResolution; 

bit (8) timeStampLength; // must be £ 64 

bit(8) OCRLength; // must be £ 64 

bit (8) AU_Length; // must be ^ 32 

bi t ( 8 ) ins tan tBi tra teLength ; 

bit (4) degradationPriorityLength; 

bit (5) AU_seqNumLength; // must be £ 16 

bit (5) packet SeqNumLength; // must be £ 16 

bit (2) extension_field_control; 



> 



if (durationFlag) { 
bit (32) timeScale; 
bit (16) accessUnitDuration; 
bit (16) compositionUnitDuration; 



if (! useTimeStampsFlag) ( 

bit (timeStampLength) startDecodingTimeStamp; 
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bit (timeStampLength) startCompositionTimeStamp; 

) 

if (hasNextAU) { 

bit (timeStampLength) next DecodingTimeSt amp ; 

) 

if (extension_field_control==OblO) 
I 

MarkerDescriptor [0. .1] markerDescriptors; 
DependencyDescriptor [0. .255) dependencyDescriptors; 



dependencyMarkersCount=0 ; 
while (true) 
{ 

bit(l) hasMoreMaxkers ; 

if (! hasMoreMaxkers) break; 



DependencyMarker dependencyMarkers [ dependancy M arkersCoun t++ ] ; 



dependencyDescriptorCount =0; 

while (true) 

{ 

bit ( 1) hasttoreDependencyDescriptor ; 

if (ihaSMoreDependencyDescriptor) break; 

DependencyDescriptor dependencyDescriptor 
[dependencyDescriptorCount++l ; 
) 

) 

3 2 Sfrwmttque 

L'entete de paquet SL pent etre configure selon les besoins de chaque flux 
elemental individuel. Les parametres qui peuvent etre selectionn<5s comprennent 
la presence, la resolution et la precision des estampilles temporelles et des 
references d'horloge. Cctte flexibilite ponnet, par exemple, une faible 
.uigmenlatioii du cnnlenu de l'entete de paquet SL. 




SLConf igDescriptor, qui fait partie du ES_Descriptor associd & un 
descripteur d'objeL 

Les parametres configurables dans Tentete de paquet SL peuvent etre 
divises en deux classes : ceux qui s'appliquent a chaque paquet SL (par exemple 
5 OCR, sequenceNumber) et ceux qui sont strictement apparentes aux unites 
d'accfes (par exemple : estampilles temporelles, accessUnitLength, instantBitrate, 
degradationPriority). 

La coionne - predefined - permet de fixer par d6faut les valeurs 
d'un ensemble de paramfetres predefinis corame detailte ci-dessous. Ce tableau 
10 pourra £tre mis a jour par amendements a ISO/IEC 14496 pour inclure les 
configurations pr6d6finies comme exig6 par les futurs profils. 



Tableau 1 - Vue d'ensemble des valeurs SLConf igDescriptor 

predefinies 



Champ de valeur 
predefini 


Description 


0x00 


Clientele (custom) 


0x01 


Entete de paquet SL nulle 


0x02 


Reservd a Tusage dans les fichiers MP4 


0x03 - OxFF 


Reserv6 & Tusage ISO 



Tableau 2 - Detail des valeurs SLConfigDescriptor predefinies 



Champ de valeur predefini 


0x01 


0x02 


UseRcces s UnitSt a r t Flag 


0 


0 


UseAccessUnitEndFlag 


0 


0 


OseRandomAccessPointFlag 


0 


0 


UsePaddingFlag 


0 


0 


(JseTimeStampsFlag 


0 


1 


UseldleFlag 


0 


0 
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DurationFlag 


0 


0 


TimeStampResolution 


1000 


- 


OCRResolution 


- 


- 


TimeS tampLength 


32 


0 


OCRlength 


- 


0 


AO length 


0 


0 


InstantBitrateLength 




0 


DegradationPriorityLength 


0 


0 


AU seqNumLength 


0 


0 


Packet SeqNumLength 


0 


0 






Champ de valeur predefini 




0x02 


UseAccessUnitStartFlag 


0 


0 


UseAccessUnitEndFlag 


0 


0 


OseRandomAccessPointFlag 


0 


0 


UsePaddingFlag 


0 


0 


UseTimeStampsFlag 


0 


1 


UseldleFlag 


0 


0 


DurationFlag 




0 


TimeStampResolution 


1000 


- 


OCRResolution 




- 


TimeS tampLength 


32 


0 


OCRlength 




yj 


AU length 


0 


0 


InstantBitrateLength 




0 


Deqradat ionPriorityLcngth 


0 


0 


r\u ^fiqllumLcnalh 


0 


0 
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x lmeoCaxe 






AccessUnitDuration 






CompositionUnitDuration 






Start Decoding TimeS tamp 






Start Compos itionTimeS tamp 







useAccessUnitStartFlag - indique que le 
accessUnitStartFlag est present dans chaque entete de paquet SL de ce 
flux elementaire. 

useAccessUnitEndFlag - indique que le accessUnitEndFlag 
est present dans chaque entete de paquet SL de ce flux €lementaire. 

Si ni useAccessUnitStartFlag ni useAccessUnitEndFlag 
ne sont actifs, cela implique que chaque paquet SL correspond a une unite d'acces 
complete. 

useRandomAccessPointFlag - indique que le 
RandomAccessPointFlag est present dans chaque entete de paquet SL de 
ce flux elementaire. 

hasRandomAccessUnitsOnlyFlag - indique que chaque paquet 
SL correspond a un point d'acces aleatoire. Dans ce cas, le 
randomAccessPointFlag n'a pas besoin d'etre utilise. 

usePaddingFlag - indique que le paddingFlag est present dans 
chaque entete de paquet SL de ce flux elementaire. 

useTimeStampsFlag - indique que les estampilles temporelles sont 
utilisees pour la synchronisation de ce flux elementaire. Elles sont transported 
dans les entete de paquet SL. Sinon, les parametres accessUni tRate, 
composi tionUnitRate, s tartDecodingTimeS tamp et 
startCompositionTimeStamp transportes dans cet entete de paquet SL 
doivent etre utilises pour la synchronisation. 

L'utilisation d'estampilles temporelles de depart et de duree 
(useTimeStampsFlag=0) est faisable uniquement sous certaines conditions, 
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incluant un environnement sans erreur. L'acces aleatoire n'est pas ais€. 

useldleFlag - indique que,idleFlag est utilise dans ce flux 
elementaire. 

durationFlag - indique que la dur£e constante des unites d'acces et 
5 des unites de composition pour ce flux Elementaire est signalee ulterieurement. 

timeStampResolution - est la resolution des estampilles temporelles 

en impulsions par seconde. 

OCRResolution - est la r6solution de la base temporelle de Fobjet en 

cycles par seconde. 

10 timeStampLength-estla longueur des champs d'estampiile 

temporelle dans les entete de paquet SL. timeStampLength doit prendre des 

valeurs entre z6ro et 64 bits. 

OCRlength - est la longueur du champ ob jectClockRef erence 

dans T entete de paquet SL. Une suite de zeros indique qu'aucun 
15 objectClockReferences n'est present dans ce flux 61ementaire. Si 

OCRstreamFlag est mis, OCRLength doit Stre zero. Sinon, OCRlength 

doit prendre des valeurs entre z6ro et 64 bits. 

AU_Length - est la longueur des champs accessUnitLength dans 

l'entete de paquet SL pour ce flux 616mentaire. AU_JLength doit prendre une 
20 valeur entre zero et 32 bits. 

instantBitrateLength - est la longueur du champ 

instan tBitrate dans l'entete de parquet SL pour ce flux elementaire. 

degradationPriorityLength - est la longueur du champ 

degradationPriority dans FentSte de paquet SL pour ce flux 61ementaire. 
25 AU_seqNumLength - est la longueur du champ 

AU_sequenceNumber dans TentSte de paquet SL pour ce flux 6Iementaire. 

packetSeqNumLength - est la longueur du champ 

packet Gequenc-sNum^er dans l'entete de paquet SL pour ce flux 

elementaire. 

i : - 2M*j ? zolI- - •;-?.« MtiJL:" pour OTrprimc la durie des unites d'acces ei des 



unit6s de composition. Une seconde est egalement divisee en ^parties 
timeScale. 

accessOnitDura t ion - la duree d'une unite d'acces est 
accessUnit Duration * 1/timeScale secondes. 
5 compositionUnitDuration - la duree d'une unite de composition 

est compositionUnitDuration * 1/timeScale secondes. ■ 

startDecodingTimeStamp - transporte Ie temps auquel la premiere 
unitd d'acces de ce flux 616mentaire doit Stre decode. II est transport^ dans la 
resolution sp6cifiee par t imeStampResolution. 
10 startCompositionTimeStamp - transporte le temps auquel l'unit6 

de composition correspondant h la premiere unit6 d'acces de ce flux etementaire 
doit etre decode. II est transport^ dans la resolution sp<5cifi€e par 
t imeStampResolution. 

extension_f ield__control - Ce champs permet d'etendre Ie SL. 
15 La valeur OlbO indique que les descripteurs doivent se trouver h la fin du 
SLConfigDescriptor. 

marker Descriptors - Cette table indique une description de 
marqueurs pour identifier les unites d'accds suivantes dans le flux 

dependencyDescriptors - Cette table indique les descripteurs de 
20 ddpendance spdcifiant comment r6f6rencer soit les unites d'accds pr6c£dentes soit 
les unites & venir. 

4. MarkerDescriptor 

La syntaxe est la suivante : 

25 class MarkerDescriptor extends BaseDescriptor : bit (8) 
tag=DependencyMarkerTag { 

int (5) encodedMarkerLength; 
MarkerLength= encodedMarkerLength + 1; 

} 

30 

5. Depen dencvDescrip tor 

5,1 svntaxe 
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abstract class DependoncyDescriptor extends BaseDescriptor I 

); 

class Sx^leBependencvDescriptor extends BaseDescriptor : bit (8) 
5 tag=SimpleDependencyTag { 
bit (2) mode; 

bit (5) dependencyLength; 
if (mode— 1 I I mode— 0) 
( 

10 bit (dependencyLength) firstvalue; 

1 

1; 

class CompXeteDependen^eseriptor extends BaseDescriptor : bit (8) 
15 tag-CompleteDependencyTag { 

bit (2) mode; 

bit (16) ESID ; 

bit (5) dependencyLength; 

if (mode=<=l I I mode==0) 
20 I 

int (dependencyLength) firstvalue; 

) 

25 5 0 s^-mantique 
5.2.1 mode 

Quatre modes sont dSfinis : 

o Mode 0 : reference vers l'avant par DTS. 

o Mode 1 : reference vers l'avant par Marqueur. 
30 o Mode 2 : reference arriere de scalability 

o Mode 3 : mode IPMP. 

Les modes 0 et 1 forcent chaque unite d'acces a faire ref6rence a la 

prochaine unite d'acces. 

Le mode 2 fore, chaque unite d'acc* a faire referenee * Punite d'aeces 
» precedente qui c. neeersaire pour decoder eette unite d'acces. (Note : Dans de 
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nombreux cas, plus de deux dependencydescriptors sont n^cessaires, pour 
se referer k deux unites d'acc&s necessaires ou plus). 

Le mode 3 permet k chaque unitd d'acces de contenir un identifiant 
opaque, qui peut etre utilise par le sysfeme IPMP, afin de decider si le decodage 
et la composition de cette unite d'acces est possible. 

Les modes 1 et 3 requierent un MarkerDescriptor dans le flux. 
5.2.2 ESID 

Ce champ optionnel identifie le flux auquel le DependencyDescriptor fait 
reference. 

Pour SimpIeDependencyDescriptor, ESID est calculi de la manure 
suivante : 

• Modes 0 et 1 : le flux courant. 

• Mode 2 : selon dependsOnESID 

• Mode 3 : pas applicable. 
dependencyLength - est la longueur, soit du marqueur (si il existe) soit 

du decodingTimeStamp. 

value - est la valeur du premier marqueur ou dts identifiant la prochaine 
unite d'acc&s k decoder 

4 Specification de Pentete ri* paq uet ST. 

6J Syntaxe 

aligned (8) class SL_PacketHeader (SLConf igDescriptor SL) { 
if (SL.useAccessOnitS tart Flag) 
bit (1) accessUnitStartFlag; 
if" (SL.useAccessUnitEndFlag) 
bit(l) accessUnitEndFlag; 
if <SL.OCRLength>0) 

bit(l) OCRflag; 
if (SL.useldleFlag) 
bit(l) idleFlag; 
if (SL.usePaddingFlag) 
bit (1) paddingFlag; 
if (paddingFlag) 

bit (3) paddingBits; 
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if (!idleFlag && { IpaddingFlag |l paddingBits ! =0) ) { 

* 

if (SL.packetSeqNumLength>0) 

bit (SL.packetSeqNumLength) packetSequenceNumber; 
5 i f ( SL . degr ada t ion P r iori tyLength> 0 ) 

bit (1) DegPrioflag; 
if (DegPrioflag) 

bit (SL.degradationPriorityLength) degradationPriority; 
if (OCRflag) 

10 bit (SL.OCRLength) objectClockReference; 

if (accessUnitStartFlag) { 

if (SL.useRandomAccessPointFlag) 
bit ( 1 ) randomAccessPointFlag; 
15 if (SL.AU_seqNumLength >0) 

bit (SL. AU_ seqNumLength) AU_sequenceNumber ; 
if (SL.useTimeStampsFlag) { 

bit(l) decodingTimeStampFlag; 
bit (1) compositionTimeStampFlag; 

20 } 

if (SL.instantBitrateLength>0) 

bit (1) instantBitrateFlag; 
if (decodingTimeStampFlag) 

bit (SL. times tampLength) decodingTimeStamp; 
25 if (compositionTiraeStampFlag) 

bit (SL. timeStampLength) compos it ionTimeS tamp; 
if (SL.AUJLength > 0) 

bit (SL.AUJLength) accessC/nitLength; 
if (instantBitrateFlag) 
30 bit (SL.instantBitrateLength) instantBitrate; 

} 

} 

if (SL.hasMarker £G beginningOf AO () ) 
< 

35 for (int J>0; X< markerDescriptorCount; 

I 
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} 

} 

for (int 1=0; I< dependencyDescriptorCount; 
{ 

5 if (dependencyDescriptor.mode»l == 0) 

I 

bit (dependencyDescriptor [I ] . depLsngth) dependencyPointerValue; 

} 

} 

10 j 

42 S6mantique 

accessUnitStartFlag - quand il vaut un, indique que le premier 
octet de la charge de ce parquet SL est le depart d'une unit6 d'acces. Si cet 
15 element de syntaxe est omis de la configuration de 1'entete de paquet SL, sa 
valeur par deTaut est connue du paquet SL precedent suivant la regie suivante : 

accessUnitStartFlag = (le paquet SL precedent a 
accessUnitEndFlag=l) ? 1 : 0. 

accessUnitEndFlag - quand il vaut un, indique que le dernier octet 
20 de la charge du paquet SL est le dernier octet de 1'unitd d'acces en cours. Si cet 
element de syntaxe est omis de la configuration de 1'entete de paquet SL, sa 
valeur par defiuit est uniquement connue apres reception du paquet SL suivant la 
regie suivante : 

accessUnitEndFlag = (le paquet SL suivant a 
25 accessUnitStartFlag==l) ? 1 : 0. 

Si ni AccessUnitStartFlag ni AccessUnitEndFlag ne sont 
configures dans 1'entete de paquet SL, cela implique que chaque paquet SL 
correspond a une seule unite d'acces, d'ou chaque accessUnitStartFlag = 
accessUnitEndFlag = 1. 

30 ° n notera « q uand 1'entete de paquet SL est configure pour utiliser 

accessUnitStartFlag mais ni accessUnitEndFlag ni 
accessUnitLength, il n'est pas garanti que le terminal puisse d&erminer la 
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fin d'une unite d'acc£s avant que la suivant ait 6te re?ue. 

OCRf lag - quand il vaut un, indique qu'un ob j ectClockRef erence 
va suivre. La valeur par defaut pour OCRf lag est zero. 

idleFlag - indique que ce flux 616mentaire sera inactif (c'est-i-dire 
5 absence de donn6es utiles) pour un laps de temps indetermine. Ce signe peut etre 
utilis6 par le d6codeur pour faire la distinction entre une absence d61ib6r6e et une 
absence due h une erreur de paquets SL suivants. 

paddingFlag - indique la presence de rempiissage dans ce paquet SL. 
La valeur par d6faut pour paddingFlag est z£ro. 
10 paddingBits - indique le mode de donnees de rempiissage a utiliser 

dans ce paquet SL. La valeur par d6faut pour paddingBits est z6ro. 

Si paddingFlag est mis et paddingBits vaut zero, cela indique 
que la charge suivante de ce paquet SL consiste uniquement en octets de 
rempiissage. accessUnitStartFlag, randomAccessPointFlag et 
15 OCRf lag ne doivent pas 6tre mis si paddingFlag est mis et paddingBits est 
z6ro. 

Si paddingFlag est mis et paddingBits est superieur & z6ro, cela 
indique que la charge de ce paquet SL est suivie par des paddingBits, form6s 
de bits a zero pour Talignement des octets de la charge. 

20 packetSequenceNumber - s'il est present, il doit etre augments 

continuellement pour chaque parquet SL comme un compteur modulo. Une 
discontinuity au ddcodeur correspond a un ou plusieurs paquets SL manquants. 
Dans ce cas, une erreur doit etre signalee a la couche de synchronisation. Si cet 
616ment de syntaxe est omis de la configuration de Fentete de paquet SL, le 

25 contrdle de la continuite des unites de flux par la couche de synchronisation ne 
peut pas Stre accomplie pour ce flux elementaire. 

Duplication des paquets SL : les flux elementaires qui ont un champ 
sequenced umber dans leurs enteles de paquet SL doivent utilisei la 
duplication rfes paquetr. SL pour la recuperation des envur*:. Lei's) pnquctfs) SL 
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SequenceNumber des paquets SL dupliques doit avoir la mSme valeur et 
chaque octet du paquet SL original doit etre duplique, a l'exception d'un champ 
obj ectClockRef erence, si present, qui doit encoder une valeur valide pour 
le paquet SL dupliqu6. 

5 degPrioFlag - quand il vaut un, indique que 

degradationPriority est present dans ce paquet. 

degradationPriority - indique I'importance de la charge de ce 
paquet SL. LestreamPriority definit la priorite de base d'un ES. 
degradationPriority d&Bnit une baisse de priorite pour ce paquet SL par 
10 rapport a la priori^ de base. La priorite pour ce paquet SL est donnee par : 

SL_PacketPriority = streamPriority -degradationPriority 
degradationPriority reste a cette valeur jusqu' a la prochaine 
occurrence. Cette indication peut 6tre utilisee par le decodeur du flux elementaire 
ainsi que par 1'adaptateur pour une instance d'une couche de distribution 
specifique. La proportion de la degradation parmi les paquets SL de differents 
flux elementaires augmente au fur et a mesure que SL_PacketPriority diminue. 

obj ectClockRef erence - contient une estampiUe temporelle objet. 
La valeur temporelle OTB t est reconstruite a partir de cette estampille temporelle 
OCR selon la formule suivante: 

20 1 = (° b j ec tCiockReference/SL.OCRResolution)+ 

k * (2 sL.ocRL eng t h/SL> QCRResolution) 

oil k est le temps que le compteur obj ectClockRef erence a couvert. 

obj ectClockRef erence est seulement present dans Tentete de 
paquet SL si OCRf lag est mis. 

25 n est possible de transporter uniquement une valeur OCR sans charge a 

Finterieur d'un paquet SL. 

La suite pr^sente la semantique des 616ments de syntaxe qui sont 
seulement presents au debut d'une unit<5 d'acces quand signale explicitement par 
accessUnitStartFlag dans le flux binaire : 

randomAccessPointFlag - quand il vaut un, indique que l'acces 
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aldatoire au contenu de ce flux elementaire est possible. 
randomAccessPointFlag doit uniquement etre mis si 
accessUnitStartFlag est mis. Si cet Element de syntaxe est omis de la 
configuration de I'entete de paquet SL, sa valeur par d6faut est la valeur de 
5 SLConf igDescriptor . hasRandomAccessUnitsOnlyFlag pour ce 
flux elementaire. 

AU^sequenceNumber - si present, il doit etre augment^ 
continuellement pour chaque unite d'acces comme un cotnpteur modulo. Une 
discontinuity au d6codeur correspond a une ou plusieurs unites d'acc&s 

10 manquantes. Dans ce cas, une erreur doit Stre signalee a 1'utilisateur de la couche 
synchronisation. Si cet element de syntaxe est omis de la configuration de Tentete 
de paquet SL, le contr61e de la continuity des unites de flux par la couche 
synchronisation ne peut pas etre ex6cut£ pour ce flux 616mentaire. 

Duplication des unites d'acces : les unites d'accSs envoySes utilisant le 

15 mSme nombre de s6quences que FAU immSdiatement pr^cedente doivent Stre 
ignorees. Une telle unit6 d'accSs dupiiquSe, dont l'original n'avait pas RAP mis, 
mais Tunite dupiiqu^e oui, permet 1'ajout de points d'acc^s aleatoire dans un flux 
6mis, permettant & des clients d'entrer dans le flux a des points d<§finis, pendant sa 
transmission, pendant que d'autres clients ^oivent dej& le flux. 

20 decodingTimeS tampFlag - indique qu'une estampille temporelle de 

decodage est presente dans ce paquet. 

compositionTimeStampFlag - indique qu'une composition 

d* estampille temporelle est presente dans ce paquet. 

accessUnitLengthFlag - indique que la longueur de cette unit6 

25 d' acces est presente dans ce paquet. 

instantBitrateFlag - indique qu'un instantBitrate est 

present dans ce paquet. 

decodingTimeS tamp - est une estampille temporelle de decodage 
comme configure duns le SLConf igDescriptor associe. Le temps de 
-u'. :: rf.n^ n| ,A- o;ue u i ii»e J'aecer roconslruii u partir de ceitc estampille 
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temporelle de decodage selon la formule : 

td = (decodingTimeStamp/SL. timeStampResolution + k* 
2 sl. tin, eS tan, P Len g th /SL t imeStampResolution 

ou k est le temps que le compteur decodingTimeStamp a englobe\ 
5 Un decodingTimeStamp doit uniquement etre present si le temps 

decodeur est different de la composition temporelle pour cette unite d'acces. 
compositionTiraeStamp - est une composition d'estampille temporelle 
comme configure dans le SLConf igDescriptor associe. La 
composition temporelle tc de la premiere unite de composition r&ulte du fait que 
10 cette unite d'acces est reconstruite a partir de cette composition d'estampille 
temporelle selon la formule : 

td= (compositionTimeStamp/SL. timeStampResolution + 
k * 2 sl. ti.estan.pLength/sL ^ timeStampResolution 

oil k est le temps que le compteur compositionTimeStamp a englobe. 
15 accessUnitLength - est la longueur de l'unit6 d'acces en octets. Si 

cet element de syntaxe n'est pas present ou a la valeur zero, la longueur de l'unite 

d'acces est inconnue. 

instantBitrate - est le taux binaire instantane en bits par seconde de 

ce flux elementaire jusqu'a ce que le prochain champ instantBitrate soit 
20 trouve\ 

markerValue - est la valeur d'un marqueur qui permet d'identifier 
l'unit€ d'acces . Ce marqueur est defini si markerDescriptors existe. 

DependencyPointe rvalue - est un indice de DTS ou d'un marqueur 
comme definit par le DependencyDescriptor. 
25 MarkerDescriptorCount : le nombre de descripteurs de marqueurs. 

DependencyDescriptorCount : le nombre de descripteurs 
dependants. 

7. semantique de decodqg g 

2J Mecanisme de referenc e avant rmndes 0 et 1 ~> 
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Le SLConf igDescriptor associe a un ES, indique la premise unite 

d'acces qui permet d'entrer dans le flux. . 

Si le mode de reference est DTS, alors le SLConfigDescriptor doit contenir 

un decodingTimeStamp. 
5 Sinon, un marqueur est utilise pour marquer chaque unit6 d'acces. 0 et -1 

ontune signification speciale : 

// 0 signifie qu'aucune autre unite d'acces suivra, 
//-lsignifie que n'importe quelle unite d'acces peut 6tre utilisee. 
Chaque unite d'acces doit contenir un marqueur et un dependencypointer 
10 pennettant a chaque unite d'acces d'indiquer la prochaine unite d'acces. 
7 o M^anisme reference arrjgre (mode 21 

Le SLConfigDescriptor definira n descripteurs de type 
DependencyDescriptor, qui indiqueront les unites d'acces dans 1'ES auquel se 
refereESID. 

15 Chaque unite d'acces du flux courant pointera les unites d'acces sur 1 ES 

dont 1'identifiant est ESID appele ES.base au moyen de DependencyPointers en 
reference aux unite* d'acces de ES.base (identifie par ESID) a travers leur DTS. 
7 -x Mndft TPMP ( mode 31 

Les DependencyPointers sont transmis au systeme IPMP avant decodage. 
20 Ces pointeurs opaques permettent aux moyens IPMP de decider s'il est possible 
ou non de decoder 1'unite d'acces. D peut repondre negativement si les clefs n'ont 
pas 6t6 recues, ou si les droits ne le permettent pas. Ce pointeur de dependance 
est M6 a 1'unite de composition apres decodage. 

II reviendra au systeme IPMP avant composition, les moyens IPMP 
25 decidant ensuite si l'unit6 peut 6tre ou non presentee. 

g Flux de riference horloge 

Un flux dlementaire de streamType = ClockReferenceStream doit Stre 
declare au moven du descripteur d'objet 11 est utilise dans le but de transporter les 
,n ,-rampillec t,m P or,l»e S de reference d'horlogc objet. Dc multiple, flux 
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elementaires dans un ensemble de nom peuvent faire reference a un tel 
ClockReferenceStream au moyen de I' element de syntaxe OCR_ES_id dans le 
SLConf igDescriptor pour eviter la transmission repetee de 1'information 
de reference horloge. Notons, cependant, que des references circulaires entre les 
flux elementaires utilisant OCR_ES_I D ne sont pas permises. 

Sur la couche de synchronisation, un ClockReferenceStream est realise" en 
configurant la syntaxe de 1'entSte de paquet SL pour ce flux empaquete au niveau 
SL de telle maniere que seules les valeurs OCR des OCRresolution et 
dCRlength requis sont presents dans TentSte de paquet SL. 

fl n'y a aucune charge de paquet SL presente dans un flux empaquet6-SL 
de streamType = ClockReferenceStream. 

Dans le DecoderConf igDescriptor pour un flux de reference . 
horloge, ObjectTypelndication doit 6tre mis sur 'OxFF, 
hasRandomAccessUnitsOnlyFlag sur un et buf f erSizeDB sur '0'. 

La suite indique les valeurs recommandees pour le > 
SLConf igDescriptor d'un flux de reference horloge : '-i 

Table 3 - SLConfigDescriptor valeurs des parametres SLConfigDescriptor d'un 

pour un ClockReferenceStream 



useAccessUnitStartFlag 


0 


useAccessUnitEndFlag 


0 


useRandomAccessPointFlag 


0 


usePaddingFlag 


0 


useTiraeStampsFlag 


0 


useldleFlag 


0 


durationFlag 


0 


timeStampResolution 


0 


timeStampLength 


0 


AU_length 


0 


de gra dationPriori tyLe ngth 


0 
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AU seqNumLength 



9. Restrictions pour des flux elementaires partageant le meme objet de 
base temporelle 

Lorsqu'il est possible de partager un objet de base temporelle entre 
5 plusieurs flux 61ementaires a travers OCRJSS_ID, un nombre de restrictions pour 
Taccds a ces flux £16mentaires et & leur traitement existent, comme suit : 

Quand plusieurs flux 61ementaires partagent un simple objet de base 
temporelle, Ies flux Elementaires sans information de reference horloge objet 
integr<5e ne doivent pas Stre utilis6s par Ie terminal, mSme s'ils sont 
10 accessibles, jusqu'a ce que le flux elementaire transportant Finformation de 

reference horloge objet devienne accessible. 

Si un flux elementaire sans information de reference horloge objet integree est 
rendu disponible au terminal apres le flux elementaire transportant 
r information de reference horloge objet, il doit etre d^livre en 
15 synchronisation avec le(s) autre(s) flux. Notons que cela implique qu'un tel 

flux ne doive pas Stre d61ivre depuis son d6but, en fonction de la valeur 
courante de T objet de base temporelle. 

Quand un flux £16mentaire transportant une information de reference horloge 
objet devient indisponible ou est utilise par ailleurs (par exemple en pause) 
20 tous les autres flux elementaires qui utilisent le meme objet de base 

temporelle doivent suivre cette approche, c'est-fc-dire devenir indisponibles 
ou Stre manipules dans le m§me sens. 

Lorsqu'un flux elementaire sans information de reference horloge objet integrde 
devient indisponible, cela n'a pas d'incidence sur les autres flux 
25 elementaires qui partagent le meme objet de base temporelle. 

10. Utilisation des o pt ions de configuration po nr les references d'horloge 




— Resolution de I'ambigulte dans la r ecuperation d'un ohfo He. h*** 
temporelle 

Du fait de la longueur limitee des valeurs objectClockReference 
ces estampilles temporelles peuvent etre ambigues. La valeur temporelle OTB 
peut etre reconstruite chaque fois qu'un objectClockReference est 
transmis dans les entetes d'un paquet SL selon la formule suivante : 
t oTB_«consttuctcd= (ob j e c t C 1 o c kRe f e r e n ce / S L . OCRRe s o 1 u t i on ) + 
k*(2 st - 0CRLen ' th /SL . OCRResolution) 

avec k etant une valeur entiere indiquant le nombre de boucles. La base 
temporelle resultante toTB^namcicdest mesuree en secondes. 

Quand le premier ob j ectClockRef erence pour un flux elementaire 
est acquis, la valeur k doit 6tre mise a un. Pour chaque occurrence suivante de 
obj ectClockRef erence la valeur k est estimee comme suit : 

Le terminal doit comprendre des moyens pour estimer la valeur de l'objet 
de base temporelle a chaque instant. 

Chaque fois qu'un objectClockReference est recu, la valeur 
estimee courante de 1'OTB t OTB cstimated doit 6tre echantillonnee. Mors, t^ ^(k) est 
evalue pour differentes valeurs de k. La valeur k qui minimise le terme 1 W^^, 
- WjccOOI doit etre consideree comme la valeur correcte de t^j reconsfnicIed . Cette 
valeur doit etre utilisee comme un nouvel apport au mecanisme d'estimation de 
Tobjet de base temporelle. 

L'application doit garantir que cette procedure produit une valeur non 
ambigue de k en selectionnant une longueur et une resolution appropri6es de 
1'element objectClockReference et une frequence suffisamment elevee 
des valeurs d'insertion de obj ectClockRef erence dans le flux elementaire. 
Les choix pour ces valeurs dependent de la gigue de delivance pour les paquets 
SL ainsi que de 1'ecart maximum pr6vu entre les horloges du terminal 
transmetteur et receveur. 

— Resolution de Pamhip uite dans la recup eratio n de l'estampille temporelle 
Du fait de la longueur Iimit6e des valeurs decodingTimeStamp et 
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compositionTimeStamp ces estampilles temporelles peuvent devenir 

ambigues, comme le monlre la formule suivante : 
^(mMTimeStamp/SL.timeStampResolutionHm (2 
SL . timeStarnpResolution) 

avec TimeStamp etant soit un decodingTimeS tamp soil un 
compositionTimeStamp et m etant une valeur entire indiquant le nombre 

de boucles. 

La valeur correcte W^, de 1'estampille temporelle peut etre estnnee 
comme suit : 

Chaque fois qu'un TimeStamp est recu, la valeur estim6e courante de 
l'OTB W — doit etre echantillonnee. ttfn) est evalu6 pour differed valeurs 
de m. La valeur m qui minimise le terme | - Um)! °* consideree 

comme la valeur correcte de t^estanip- 

L'application peut choisir, s6parement pour chaque flux elementaire 
individuel, la longueur et la resolution des estampilles temporelles, afin de 
respecter ses exigences sur le positionnement non ambigu des ev6nements 
temporels. Ce choix depend du temps maximum pendant lequel un paquet SL 
avec un TimeStamp peut etre envoye, apres le moment indique par le 
TimeStamp, ainsi qu'a la precision demandee au positionnement temporel. 
m 2 remarq^ sur l^age des references ^M^^^L^^^ 
tem porelles 

La ligne temporelle d'une base de temps objet permet de distinguer deux 
instants separ6s par plus d'l/SL.OCRResolution. OCRResolution doit 
6tre choisi suffisamment grand pour obtenir la precision dont a besom 
25 Y application pour synchroniser un ensemble de flux elementaires. 

Les estampilles temporelles et de composition permettent de distinguer 
deux instants separes par plus d'l/SL . timeStarnpResolution . 
timeStampResolucion doit etre choisi suffisamment grand pour obtemr la 
nr ^i„„ dont a bcoin I mplication en »erme de repcrage des unites d'acces pour 



15 



20 



41 



15 



Un TimeStampResolution plus elevS que le OCRRe solution ne 
permettra pas d'obtenir une meilleure discrimination entre Ies evenements. Si 
TimeStampResolution est plus faible que le OCRResolution, les 
evenements pour ce flux specifique ne peuvent pas etre reperes avec la precision 
5 maximum possible avec ce OCRResolution donne. 

Le parametre OCRLength est signals dans la configuration de 1'entSte 
SL. 2 SL OCRI>en 9 th /sL . OCRResolution est l'intervalle de temps couvert par 
le compteur ob j ectClockRef erence avant qu'il boucle. OCRLength doit 
etre choisi suffisamment Sieve" pour respecter les besoins de Implication pour un 
10 positionnement non ambigu des evenements temporeis pour un ensemble de flux 
SISmentaires. 

Lorsqu'une application connaft la valeur k definie plus haut, la ligne 
temporelle OTB est claire pour chaque valeur temporelle. Quand I'applicatiqn ne 
peut pas reconstruire le facteur k, comme par exemple dans une application qui 
permet l'acces alSatoire sans information complSmentaire, la ligne temporelle 
OTB est ambigug modulo 2 SL 0CRL -^VSL. OCRResolution. Ainsi, chaque 
estampille temporelle se rSfSrant a cet OTB est ambigue. II peut, cependant, etre 
consider^ clair a I'int6rieur d'un environnement duplication a travers la 
connaissance de la gigue maximum supposSe et des contraintes sur la durSe 
20 pendant laquelle une unitS d'accSs peut etre envoySe avant son instant de 
decodage. 

Notons que les flux SISmentaires qui choisissent un intervalle de temps 

oSL . timeStampLength / 0 T . . _ ^_ 

/SL. timeStampResolution supSrieur que 
2 SL - 0CRL » n « th /SL. OCRResolution ne peuvent repSrer de facon non ambigue 
25 les evenements temporeis que dans le plus petit des deux intervalles. 

Dans certains cas, lorsque k et m ne peuvent Store estimes correctement, le 
modele tampon peut Stre transgressS, ce qui entraine des operations et des 
resultats imprSvisibles du dScodeur. 

Par exemple, si on considere une application qui veut synchroniser les flux 
30 SISmentaires avec une precision d' 1 ms, OCRResolution doit etre choisi Sgal ou 
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sup6rieur & 1000 (le temps entre deux impulsions successives de TOCR est alors 
egal k 1ms). Supposons OCRResolution=2000. 

L' application suppose une gigue entre !e STB et le OTB de 0.1% (c'est-a- 
dire 1ms par seconde). Les horloges doivent par consequent etre ajustes au moins 
5 chaque seconde (c'est-St-dire, dans le pire des cas, que ies horloges auront devie 
d'lms, ce qui est la contrainte de precision). Supposons que des 
objectClockRef erence sontenvoyes chaque Is. 

L' application veut avoir une ligne temporelle OTB claire de 24h sans avoir 
besoin de reconstruire le facteur k. Le OCRLength est alors choisi en 
10 consequence de m6me que 2 SL - 0CRLen ^ rth /SL . OCRResolution=24h. 

Supposons maintenant que T application veut synchroniser les 6v6nements 
h l'intSrieur d'un flux €16mentaire seul avec la precision de 10 ms. 
TimeStampResolution doit Stre choisi 6gal ou sup6rieur & 100 (le temps 
entre deux impulsions successives du Time St amp est alors 6gal a 10ms). 
15 Supposons TimeStampResolution=200. 

L' application veut Stre capable d'envoyer les unites d'accfes & un 
maximum d'une minute avant leur temps d6codeur ou de composition. Le 
timeStampLength est alors choisi comme 

2SL. timeStainpLength /SL . timeStampResolution = 2 minutes. 

20 
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REVENDICATIONS 

1. Proc6d6 de transmission d'au moins un flux de donnees vers au moins un 
terminal, le ou lesdits flux etant organises en unites de flux, 

caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de facon a optimiser les traitements dans ledit terminal et/ou le d^bit 
utile du ou desdits flux. 

2. Procede" de transmission selon la revendication 1, caracteris6 en ce qu'au 
moins un desdits pointeurs pointe vers au moins une unite de flux dudit flux ou 
d'un autre flux susceptible d'avoir ete recue precddemment dans un terminal, dite 
unite anterieure necessaire, 

de facon qu'un traitement de ladite unite de flux ne soit pas effecnte, dans ledit 
terminal, si la ou lesdites unites anterieures necessaires n'ont pas ete recues.. 

3. Procecte de transmission selon la revendication 2, caracteris€ en ce qu'il 
comprend la transmission d'au moins deux flux de donnees transmis statement, 
une unite de flux d'un premier flux pointant vers au moins une unite anterieure 
necessaire d'au moins un second flux, ladite unite de flux du premier flux 
comprenant des donn6es d'enrichissement des donnees contenues dans le ou 
lesdits seconds flux. 

4. Procecte de transmission selon la revendication 3, caracterise" en ce que 
lesdits flux de donnees correspondent a des niveaux hierarchiques differents d'un 
codage hierarchique, le traitement d'une unite de flux d'un niveau hterarchique 
domte n'&ant effecfate que si les unites de flux du ou des niveaux hierarchiques 
infeneurs correspondants ont 6t6 regus. 

5. Procecle de transmission selon l'une quelconque des revendicadons 3 et 4, 
caracterise" en ce que ladite unite de flux pointe sur au moins une unite anterieure, 
ddfinissant une sequence d' unites anterieures necessaires. 

6. Proc&ie" de transmission selon l'une quelconque des revendications 2 a 5, 
caracteris6 en ce qu'au moins un desdits pointeurs permet de retrouver au moins 
une unite anterieure necessaire comprenant des donnees permettant le decodage 
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et/ou le decryptage de l'unite de flux consideree. 

7. Proced6 de transmission selon la revendication 6, caracterisfi en ce que la 
ou lesdites unites ant6rieures necessaires comprend des donnees permettant a un 
terminal de decider si les donnees d'une unite de flux consideree doivent etre 

5 d6cod£es et/ou d&xyptees, puis affichees apres decodage. 

8. Procede de transmission selon Tune quelconque des revendications 1 a 7, 
caracterise en ce qu'au moins un desdits pointeurs pointent vers des donnees 
susceptibles d'etre connues dudit terminal, de fa$on que ce dernier puisse decider 
de sa capacity ou de son incapacit6 h traiter l'unit6 de flux correspondante. 

10 9. Procede de transmission selon Tune quelconque des revendications 1 a 8, 
caracterise en ce qu'au moins une desdites unites de flux comprend au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, 
susceptible d'etre re?ue prochainement. 

10. Procede de transmission selon la revendication 9, caracterise en ce que la 
15 ou lesdites unites de flux susceptible d'etre regue prochainement possede en 

marqueur, permettant de faire un lien avec le ou lesdits pointeurs. 

11. Procede de transmission selon Tune quelconque des revendications 9 et 10, 
caract6ris6 en ce que les pointeurs d'au moins deux unites de flux similaires 
transmises a des instants distincts pointent vers une meme unite de flux 

20 susceptible d'Stre regue prochainement- 

12. Procede de transmission selon Tune quelconque des revendications 1 & 1 1, 
caracterise en ce qu'il met en ceuvre un indicateur indiquant le role du ou des 
pointeurs, parmi au moins deux des r61es appartenant au groupe comprenant : 

designation d'au moins une unite de flux anterieure devant 6tre 
25 decodee pour permettre la prise en compte de l'unite de flux 

consid£r£e ; 

designation d'au moins une unite de flux anterieure comprenant des 
Jonn&s necessaires nu decodage et/ou au decryptage de Tunite de 
flux consideree, et/ou d'une reference a un etat d'un systdme de 
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designation d'au moins une unite de flux posterieure. 
13. Procede de transmission selon la reyendication 12, caracteris6 en ce qu'au 
moins certaines desdites unites de flux comprennent un descripteur de 
dependance, defmissant Iedit role. 
5 14. Proc6d6 de transmission selon 1'une quelconque des revendications 1 a 13, 
caracterise en ce qu'au moins certaines desdites united de flux comprennent un 
marqueur de dependance, permettant son identification en tant qu'unite anterieure 
necessaire. 

15. Proced6 de transmission selon 1'une quelconque des revendications 1 a 14, 
10 caracteris6 en ce qu'au moins certaines desdites unites de flux comprennent un 

marqueur d' identification de ladite unit€ de flux dans Iedit flux. 

16. Procecie de transmission selon 1'une quelconque des revendications l a 15, 
caracterise en ce qu'il est mis en ceuyre au niveau synchronisation, de facon 
qu'aucun traitement prealable d'une unit6 de flux regue ne soit necessaire. 

15 17. Flux de donn6es transmis selon le proceed de transmission de 1'une 
quelconque des revendicadons 1 a 16. 

18. Flux de donnees transmis vers et/ou regu par au moins un terminal, et 
organise" en unites de flux transmises independamment les unes des autres, • 
caracterise en ce qu'au moins certaines desdites unites de flux comprennent au 

20 moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fagon a opdmiser les traitements dans Iedit terminal et/ou le delrit 
utile du ou desdits flux. 

19. Flux de donnees selon la revendication 18, caract6ris€ en ce qu'au moins 
un desdits pointeurs pointe vers au moins une unite de flux dudit flux ou d'un 

25 autre flux susceptible d'avoir ete recue prec&Jemment dans un terminal, dite unite 
anterieure necessaire, 

de fagon qu'un traitement de ladite unit6 de flux ne soit pas effectu6, dans Iedit 
terminal, si la ou lesdites unites anteiieures n6cessaires n'ont pas ete regues. 

20. Serveur de donnees destinees a etre transmises vers au moins un terminal, 
30 sous la forme d'au moins un flux de donnees organist en unites de flux transmises 
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independamment les unes des autres, 

caracteris6 en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux, de fagon a optimiser les traitements dans ledit terminal et/ou le d6bit 
5 utile du ou desdits flux. 

21. Terminal apte a recevoir au moins un flux de donn^es organise en unites 
de flux transmises independamment les unes des autres, 

caracteris6 en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
10 autre flux, de fagon a optimiser les traitements dans ledit terminal et/ou le debit 
utile du ou desdits flux. 

22. Procede de reception d'au moins un flux de donnees organise en unites de 
flux transmises independamment les unes des autres, 

caract6rise en ce qu'au moins certaines desdites unites de flux comprennent au 
15 moins un pointeur pointant vers au moins une unit6 de flux dudit flux ou d'un 
autre flux, de fa?on a optimiser les traitements dans ledit terminal et/ou le d6bit 
utile du ou desdits flux. 

23. Proc6de de reception selon la revendication 22, caract6rise en ce qu'au 
moins un desdits pointeurs pointe vers au moins une unit£ de flux dudit flux ou 

20 d'un autre flux susceptible d' avoir 6t6 regue precedemment dans un terminal, dite 
unite ant6rieure necessaire, 
et en ce qu'il comprend les Stapes suivantes : 

analyse du ou desdits pointeurs d'une unite de flux ; 
traitement de ladite unite de flux si la ou lesdites unites antfirieures 
25 necessaires ont 6t6 regues. 

24. Utilisation du procede de transmission selon Tune quelconque des 
revendications 1 a 16 pour une des applications appartenant au groupe 
eouipreuant . 

diffusion systematique d'un message avant acees a un programme 

* : tk :\ ionni par un nil Msntem \ 




accds conditionnel k un niveau de quality particulier et/ou a 
option particuliere d'un programme ; 
television interactive. 
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